DotNetNuke can use jQuery to enable popup style and image rotator effects. These are great and a big improvements on technologies like flash. However it is not hard to find two separately coded jQuery modules that can cause conflicts when used on the same page as each other.
The Reason
The reason in most cases is that modules can be hard coded to use their own version of jQuery. (Think of jQuery as a plugin that is required for the code to load onto the web page).
The library that powers jQuery is often updated to include new features. Earlier version of DotNetNuke did not have any ability to load jQuery or reference it as “part” of the core of DNN.
So for any module written for early DNN versions, the library plugin for jQuery needed to be included or referenced to an online source like the free Google jQuery reference.
If two module are on the same page and calling different versions of jQuery into play, it is likely that one of the modules will conflict and fail to work correctly. Often it will be the more advanced or later built module that fails.
DotNetNuke Solution
The solution to this is to built a common core library into the core of DotNetNuke, and allow modules and other code to reference this single source when calling on the jQuery library for any reason.
DotNetNuke have included jQuery as an option in the host settings, to allow it to be loaded from there.
They run a release version of the jQuery library that is presumably updated with releases of DotNetNuke. The last version of DotNetNuke 5x shows this.
Modules can either call this library, or use their own library.
How Modules Use DNN version of jQuery or their Own version
Well developed code or modules will usually have a setting that allows you to reference the HOST DNN version of jQuery, or call into play the version that shipped with the module.
On our modules, we use a tab setting that looks like this:
If the “Load jQuery” is ticked, the module will use the jQuery library that is shipped with the module.
If the option is not ticked, the module will use the DotNetNuke included version of jQuery.
Best Resolution
When conflicts occur, the best way to resolve it is to ensure that both modules are referencing the exact same jQuery library version. The easy way to do this is to ensure that both modules are NOT using their own version, or in our case “Load JQuery” is NOT CHECKED. 
And, ensure that any other modules are also not referencing their own version of jQuery but are looking to the hosted jQuery. (Talk to the module developer on how to do this.)
Other Possible Problems
1. One of the modules may require a feature that is more advanced than the the hosted jQuery version. In this case, a later jQuery library will need to be referenced. To allow this to be done, DotNetNuke have allowed you to reference a URL for another version of jQuery.
For example, in our Mushroom Image module for DotNetNuke, the rotator effect requires a later version of jQuery than the last version of DotNetNuke 5x references. 1.4.4. To set a later version, you simply find an online resource like this Google hosted jQuery library:
And enter that URL into your HOST jQuery settings.
2. Another issue is that there may be a conflict in the jQuery script used to call the module actions. We have included the ability to customize the script used to reduce conflict.
Naturally this is an option for advanced users, and not all modules have this feature.
What is the Take Home Message?
When a conflict occurs, there is usually no “developer” at fault, but rather an incompatibility between the ways that the jQuery is being called. Don’t assume that the last module installed is to blame.
In most cases the conflicts can be resolved using the steps outlined above. This assumes that the modules installed have similar flexibility as we do in our modules.
